In many information processing applications, a server application running on a host or server computer in a distributed network provides processing services or functions for client applications running on terminal or workstation computers of the network which are operated by a multitude of users. Common examples of such server applications include software for processing class registrations at a university, travel reservations, money transfers and other services at a bank, and sales at a business. In these examples, the processing services provided by the server application may update databases of class schedules, hotel reservations, account balances, order shipments, payments, or inventory for actions initiated by the individual users at their respective stations.
Often, server applications require coordinating activities on multiple computers, by separate processes on one computer, and even within a single process. For example, a money transfer operation in a banking application may involve updates to account information held in separate databases that reside on separate computers. Desirably, groups of activities that form parts of an operation are coordinated so as to take effect as a single indivisible unit of work, commonly referred to as a transaction. In many applications, performing sets of activities as a transaction becomes a business necessity. For example, if only one account is updated in a money transfer operation due to a system failure, the bank in effect creates or loses money for a customer.
A transaction is a collection of actions that conform to a set of properties (referred to as the "ACID" properties) which include atomicity, consistency, isolation, and durability. Atomicity means that all activities in a transaction either take effect together as a unit, or all fail. Consistency means that after a transaction executes, the system is left in a stable or correct state (i.e., if giving effect to the activities in a transaction would not result in a correct stable state, the system is returned to its initial pre-transaction state). Isolation means the transaction is not affected by any other concurrently executing transactions (accesses by transactions to shared resources are serialized, and changes to shared resources are not visible outside the transaction until the transaction completes). Durability means that the effects of a transaction are permanent and survive system failures. For additional background information on transaction processing, see, inter alia, Jim Gray and Andreas Reuter, Transaction Processing Concepts and Techniques, Morgan Kauffmann, 1993.
In many current systems, services or extensions of an operating system referred to as a transaction manager or transaction processing (TP) monitor implement transactions. A transaction is initiated by a client program, such as in a call to a "begin.sub.13 transaction" application programming interface (API) of the transaction monitor. Thereafter, the client initiates activities of a server application or applications, which are performed under control of the TP monitor. The client ends the transaction by calling either a "commit_transaction" or "abort_transaction" API of the TP monitor. On receiving the "commit_transaction" API call, the TP monitor commits the work accomplished by the various server application activities in the transaction, such as by effecting updates to databases and other shared resources. Otherwise, a call to the "abort_transaction" API causes the TP monitor to "roll back" all work in the transaction, returning the system to its pre-transaction state.
In systems where transactions involve activities of server applications on multiple computers, a two-phase commit protocol often is used. In general, the two-phase commit protocol centralizes the decision to commit, but gives a right of veto to each participant in the transaction. In a typical implementation, a commit manager node (also known as a root node or transaction coordinator) has centralized control of the decision to commit, which may for example be the TP monitor on the client's computer. Other participants in the transaction, such as TP monitors on computers where a server application performs part of the work in a transaction, are referred to as subordinate nodes. In a first phase of commit, the commit manager node sends "prepare_to_commit" commands to all subordinate nodes. In response, the subordinate nodes perform their portion of the work in a transaction and return "ready_to_commit" messages to the commit manager node. When all subordinate nodes return ready_to_commit messages to the commit manager node, the commit manager node starts the second phase of commit. In this second phase, the commit manager node logs or records the decision to commit in durable storage, and then orders all the subordinate nodes to commit their work making the results of their work durable. On committing their individual portions of the work, the subordinate nodes send confirmation messages to the commit manager node. When all subordinate nodes confirm committing their work, the commit manager node reports to the client that the transaction was completed successfully. On the other hand, if any subordinate node returns a refusal to commit during the first phase, the commit manager node orders all other subordinate nodes to roll back their work, aborting the transaction. Also, if any subordinate node fails in the second phase, the uncommitted work is maintained in durable storage and finally committed during failure recovery.
In transaction processing, it is critical that the client does not pre-maturely commit a server application's work in a transaction (such as database updates). For example, where the activity of a server application in a transaction is to generate a sales order entry, the server application may impose a requirement that a valid sales order entry have an order header (with customer identifying information filled in) and at least one order item. The client therefore should not commit a transaction in which the server application generates a sales order before both an order header and at least one order item in the sales order has been generated. Such application-specific requirements exist for a large variety of server application activities in transactions.
Historically, pre-mature client committal of a server application's work in a transaction generally was avoided in two ways. First, the server application can be programmed such that its work in a transaction is never left in an incomplete state when returning from a client's call. For example, the server application may implement its sales order generation code in a single procedure which either generates a valid sales order complete with both an order header and at least one order item, or returns a failure code to cause the client to abort the transaction. The server application's work thus is never left in an incomplete state between calls from the client, and would not be committed prematurely if the client committed the transaction between calls to the server application.
Second, the client and server application typically were developed together by one programmer or a group of programmers in a single company. Consequently, since the programmers of the server application and client were known to each other, the server application programmers could ensure that the client was not programmed to commit a transaction between calls that might leave the server application's work in an incomplete state. For example, the client's programmers could be told by the server application programmers not to call the commit_transaction API after a call to the server application that sets up an order header and before a call to the server application that adds an order item.
These historical approaches to avoiding pre-mature committal of server application work in a transaction are less effective for, and in some ways antithetical to, component-based server applications that are programmed using object-oriented programming techniques.
In object-oriented programming, programs are written as a collection of object classes which each model real world or abstract items by combining data to represent the item's properties with functions to represent the item's functionality. More specifically, an object is an instance of a programmer-defined type referred to as a class, which exhibits the characteristics of data encapsulation, polymorphism and inheritance. Data encapsulation refers to the combining of data (also referred to as properties of an object) with methods that operate on the data (also referred to as member functions of an object) into a unitary software component (i.e., the object), such that the object hides its internal composition, structure and operation and exposes its functionality to client programs that utilize the object only through one or more interfaces. An interface of the object is a group of semantically related member functions of the object. In other words, the client programs do not access the object's data directly, but must instead call functions on the object's interfaces to operate on the data.
Polymorphism refers to the ability to view (i.e., interact with) two similar objects through a common interface, thereby eliminating the need to differentiate between two objects. Inheritance refers to the derivation of different classes of objects from a base class, where the derived classes inherit the properties and characteristics of the base class.
Object-oriented programming generally has advantages in ease of programming, extensibility, reuse of code, and integration of software from different vendors and (in some object-oriented programming models) across programming languages. However, object-oriented programming techniques generally are antithetical to the above described historical approaches to avoiding pre-mature committal of server application work.
First, object-oriented programming techniques encourage accomplishing work in multiple client-to-object interactions. Specifically, object-oriented programming encourages setting an object's properties in calls to separate member functions, then carrying out the work with the set properties in a call to a final member function. For example, a money transfer object may provide a set of member functions that includes a SetDebitAccount( ) function, a SetCreditAccount( ) function, a SetTransferAmount( ) function, etc. that the client program calls to set the object's properties. Finally, the client program may call a TransferMoney( ) function to cause the object to perform the money transfer operation using the accumulated object properties (also referred to as the object's state). Between these separate client-object interactions, server application work may often be left in an incomplete state. The object-oriented programming style thus is contrary to the above described approach to avoiding pre-mature committal wherein server application work is never left incomplete on return from a client call.
Second, object-oriented programming also encourages integration of objects supplied from unrelated developers and companies. When the server application is built from object classes supplied from unrelated vendors, there is less opportunity for direct collaboration between developers of the server application and the client. Without direct collaboration, the developer of an object used in a server application generally cannot ensure that the developer of a client will not commit a transaction between calls to the server application object which leave the server application's work in an incomplete state. Thus, the second above described approach to avoiding pre-mature committal also is less effective in component-based server applications.
The present invention avoids premature committal of component-based server application work by allowing a server application component to have control over whether the client can commit a transaction involving the component's work. According to one aspect of the invention, an execution environment for server application components provides functions that a server application component calls to temporarily and reversibly enable and disable, respectively, committal of a transaction in which the component participates. The component calls the function to disable committal upon returning from a client call that leaves the component's work in an incomplete state. On the other hand, if the component's work is in a complete or valid state, the component calls the function to enable transaction committal on return from the client call. The invention thus implements an approach to avoid premature committal that allows a server application to leave its transactional work in an incomplete state between client interactions, and allows easier integration of application components from independent sources (e.g., by not relying on direct collaboration between developers to avoid premature committal).
Additional features and advantages of the invention will be made apparent from the following detailed description of an illustrated embodiment which proceeds with reference to the accompanying drawings.